\documentclass[a4paper]{article}

\usepackage[dutch]{babel}
\usepackage[a4paper]{geometry}
\usepackage{fullpage}
\usepackage{url}
\usepackage{graphicx}

\begin{document}

\title{Projectmanagement \\ \textbf{Taak 2}}
\author{Groep 8}

\maketitle

\section{Berekening geschatte duur}

De verwachte duur van de activiteiten werd berekend op basis van een minimumduur $a$, maximumduur $b$ en verwachte duur $m$, die door de teamleden gezamenlijk werden geschat en gemotiveerd. Hierbij wordt verondersteld dat de kans dat een taak minder lang duurt dan $a$ kleiner is dan $1\%$ en dat de kans dat een taak langer duurt dan $b$ eveneens kleiner is dan $1\%$. $T_E$ werd berekend op basis van de formule $T_E = \frac{a + 4m + b}{6}$. De duur van iedere activiteit wordt uitgedrukt in dagen.

Volgens onze schattingen hebben we maximaal $155,5$ dagen nodig om het project te realiseren, dit ligt $35,5$ dagen boven de beschikbare tijd van $24$ werkweken, oftewel $120$ dagen. De berekende verwachte tijd ligt echter op $101$ dagen, wat betekent dat het project binnen de gebudgetteerd tijd van $24$ werkdagen zou moeten kunnen gerealiseerd worden. Er is zelfs een speling over van $19$ dagen.

In Tabel~\ref{table:overzicht} wordt een overzicht gegeven van de berekeningen per activiteit. De activiteit nummers komen overeen met de nummers in het WBS diagram dat als appendix aan dit document werd toegevoegd (dit is de gemeenschappelijke WBS die in taak 1 wordt gemotiveerd).

Om te berekenen met welke kans het project binnen de opgegeven tijd van $120$ dagen kan worden afgerond, gebruiken we de excel-functie NORMDIST, zoals omschreven in het handboek. 
We gebruikten hiervoor het kritisch pad. 
$$\textrm{NORMDIST}(120;38,83;2,90354;1) = 1$$

De kans op tijdig afronden bedraagt dus $100\%$. Er is geen reden om nog andere paden in beschouwing te nemen, gezien de kans op tijdig afronden van zo een pad alleen maar nog `hoger' kan zijn.

Merk op dat dit percentage natuurlijk erg onrealistisch is, maar dit kan worden verklaard doordat de taken hier worden uitgedrukt in manuren en niet in kalenderdagen. De berekening is dus niet gebaseerd op een concrete planning in de tijd, waarbij rekening werd gehouden met de toekenning van resources, resource leveling enz. zoals dit in de praktijk zou gebeuren.

\begin{table}
\begin{tabular}{lllllp{7cm}}
\textbf{Taak}	&\textbf{a}	&\textbf{m}	&\textbf{b}	&{$\textbf{T}_\textbf{\sc e}$} & \textbf{Motivering}\\
\hline
1.1	&2	&3	&5	&3,17 & \footnotesize Zou in principe vrij snel moeten gaan, we houden bij het maximum rekening met eventuele afspraken die moeten verschoven worden en de noodzaak om aan te passen aan agenda van anderen. \\
1.2	&1	&3	&5	&3,00 & \footnotesize Hangt af van documentatie, kan vlot gaan, maar ook zeer tijdrovend zijn. \\
1.3	&0,5	&1	&2,5	&1,17 & \footnotesize Dit lijkt eenvoudiger dan het voorgaande puntje. \\
1.4	&1	&2,5	&4	&2,50 & \footnotesize Dit is een belangrijk aspect in onze implementatie. Heel slechte beveilig/ heel goede beveiliging zijn natuurlijk makkelijk te detecteren. Een grondige analyse kan echter ook veel tijd in beslag nemen. \\
1.5	&1	&2	&5	&2,33 &\footnotesize Dit kan vlot gaan, bijvoorbeeld als er veel kan worden hergebruikt, maar kan ook weer de nodige tijd vergen. We denken wel dat deze taak eerder vlot zou moeten verlopen. \\
\hline
2.1	&2,5	&4	&6	&4,08 & \footnotesize Kan snel gaan als we een deel van de database kunnen hergebruiken.\\
2.2	&4	&6	&10	&6,33 & \footnotesize Systeemarchitectuur gaat over meer detail, hier zal dus meer tijd in moeten worden ge\"investeerd. \\
2.3	&2	&2,5	&4	&2,67 & \footnotesize We veronderstellen dat de huidige interface grotendeels hergebruikt kan worden. \\
\hline
3	&5	&10	&12	&9,50 & \footnotesize We verwachten dat er altijd relatief veel onverwachte problemen zullen voorkomen, hier wordt rekening mee gehouden in de berekening van $m$. \\
\hline
4.1	&4	&5	&7	&5,17 & \footnotesize Het framework is de fundering van de applicatie, hier zal veel tijd in moeten worden gestoken. \\
4.2	&1	&1,5	&3	&1,67 & \footnotesize In het beste geval kunnen we veel van de bestaande code hergebruiken. \\
4.3	&1	&1,5	&3	&1,67 & \footnotesize idem.\\
4.4	&1	&1,5	&3	&1,67 & \footnotesize idem. \\
4.5	&1	&2,5	&4	&2,50 & \footnotesize Deze module kan meer moeilijkheden met zich meebrengen vanwege extra features zoals iCal. \\
\hline
5.1	&2,5	&3,5	&5	&3,58 & \footnotesize Afhankelijk van de documentatie die reeds in de implementatie fase werd toegevoegd. \\
5.2	&2	&3	&5	&3,17& \footnotesize Mogelijke herbruikbaarheid, aanpassingen \ldots \\
\hline
6.1	&2,5	&5	&15	&6,25 &\footnotesize Dit kan sterk verschillen en hangt af van de fouten die worden gevonden. \\
6.2	&5	&7	&10	&7,17 & \footnotesize Hangt sterk af van hoe het personeel meewerkt. \\
\hline
7.1	&5	&7,5	&15	&8,33 & \footnotesize Hangt af van bijvoorbeeld inconsistenties in de data, dit kan zwaar tegenvallen. \\
7.2	&3	&5	&7	&5,00 & \footnotesize Hangt af van hoe strikt afspraken i.v.m. code worden nageleefd. \\
\hline
8	&10	&20	&25	&19,17 & \footnotesize Gebeurt in groep, hierdoor zijn er veel manuren nodig.\\
\hline
\textbf{TOTAAL}	&57	&97	&155,5	&100,1\\
\end{tabular}
\caption{Overzicht van berekeningen}
\label{table:overzicht}

\end{table}



\section{Afhankelijkheden}

De duur van de activiteiten, zoals weergegeven in Tabel~\ref{table:overzicht}, werden gecombineerd met de verschillende afhankelijkheden die we als team konden identificeren. Deze worden hieronder opgesomd.

\begin{itemize}
\item De volledige analyse fase komt voor de design fase;
\item De analyse van de mogelijkheden kan pas worden uitgevoerd na de andere analyse fasen;
\item Het database design kan pas worden uitgevoerd na het design van de systeem architectuur;
\item De database implementatie kan pas na het database design worden uitgevoerd;
\item De systeem architectuur design fase moet voor de back-end fase plaatsvinden;
\item Het implementeren van het framework moet gebeuren voor de implementatie van de modules;
\item Het volledige design moet zijn afgewerkt vooraleer de documentatie fase kan worden ingezet;
\item Het UI design vindt plaats voor de UI implementatie;
\item De database, back-end en front-end implementatie moeten gerealiseerd zijn voor de validatie/testing fase kan worden ingezet;
\item De data migratie vindt pas plaats na de database implementatie;
\item De database, back-end en front-end implementatie vinden plaats voor de integratie fase;
\item De interne tests vinden plaats voor de tests met het personeel;
\item Andere fases kunnen in principe parallel plaatsvinden.
\end{itemize}

\section{PERT schema}

De afhankelijkheden in combinatie met de duren van de taken werden in een PERT schema gegoten, dit is te zien in Figuur~\ref{fig:pert}. Er werden drie milestones in aangebracht, zijnde analyse, design en back-end realisatie. Het kritisch pad wordt eveneens aangegeven.

\begin{figure}
\begin{center}
\includegraphics[height=\textheight, clip, trim=80 80 350 130]{all/PERT.pdf}
\end{center}
\caption{PERT schema}
\label{fig:pert}
\end{figure}

\appendix

\section{WBS}

\begin{center}
\includegraphics[height=0.16\textheight, angle=90]{all/WBS_gemeenschappelijk.png}
\end{center}

\end{document}
